One of the greatest threats to computer users today is malware, such as Internet viruses and worms, that target security holes in conventional operating system (OS) software. In recent years, software patches, security applications, and operating system upgrades have closed many of the security holes exploited by the malware developers. For example, malware protections, such as recently released Network Driver Interface Specification (NDIS) Intermediate (IM) drivers for a Windows operating system, provide features such as firewall, quality of service, IP security, and the like by monitoring and filtering the incoming and outgoing network traffic. Unfortunately, older operating systems like Windows NT 4.0, Windows 3.1 and Windows95® are not able to take advantage of the new NDIS IM drivers built for newer operating systems like Windows XP and Windows 2003. These legacy operating systems thus remain susceptible to Internet viruses and worms and network denial of service (DOS) attacks.
Due to the significant costs and business disruptions that would be incurred in upgrading the installed based of legacy operating systems users to newer, more secure, operating systems, it is likely that users of these legacy operating systems will continue to be vulnerable to malware for some time to come unless a technology path is provided that enables such users to maintain their legacy operating systems yet provide the most up-to-date malware protections. Virtual machine (VM) technology provides one possible technology path for protecting legacy operating systems. In conventional VM systems such as Virtual Server available from Microsoft Corporation, the legacy operating systems function as guests of a host operating system containing the up-to-date malware protections. Unfortunately, the legacy operating systems (guests) are not able to take advantage of the networking infrastructure of the host operating system and thus remain as susceptible to attack when run as a guest on a newer operating system like Windows XP or Windows 2003 as when run on real hardware. Moreover, even if solutions such as firewall, quality of service, IP security, and the like exists for a guest operating system, such solutions are run within the guest operating system and it is quite difficult to manage these solutions inside different guest operating systems.
FIG. 1 illustrates a conventional VM system 10 including a host OS 20 (e.g., Windows XP or Windows 2003) that emulates a legacy guest OS 30 (e.g., Windows 3.1, Windows NT 4.0, or Windows95®). As illustrated, the guest OS 30 communicates with the host OS 20 via a point-to-point (P2P) connection 40, such as a virtual Ethernet cable. The host OS 20 includes a physical network interface card (NIC) 21 that physically connects the host OS 20 to a data network such as the Internet for accepting network data traffic. A host OS 20 with malware protections such as an NDIS IM filter may also include Virtual Server NDIS IM driver 22 that provides one-to-one connectivity between the physical NIC 21 and the incoming and outgoing network traffic of the host OS 20. In the case of conventional Internet communications, the incoming/outgoing TCI/IP traffic 23 to/from applications within the host OS 20 pass through a host NDIS IM driver 24 for monitoring and/or filtering of the host network traffic. NDIS IM driver 24 is, in turn, connected to a port of the Virtual Server NDIS IM driver 22 via a virtual NIC (VNIC) 25. The Virtual Server NDIS IM driver 22 provides a one-to-one connection between the VNIC 25 and the physical NIC 21 to provide routing of network traffic coming from the host OS 20 and the guest OS 30.
As further illustrated in FIG. 1, the guest OS 30 includes a guest networking stack 31 that stacks communications requests to/from the guest OS 30. The communications generated by applications of the guest OS 30 pass through a VNIC 32, over the point-to-point (P2P) open connection, which may be a Virtual Ethernet cable (a shared memory or any other communication method between a guest and a host) 40, and into the Virtual Server NDIS IM driver 22 as illustrated. Typically, the VNIC 32 sends data to/from host OS 20 over the P2P open connection 40 following any appropriate Ethernet protocol. Unfortunately, this implementation also does not permit the guest OS 30 to access the filtering functionality of the NDIS IM driver 24; therefore, the guest OS 30 remains vulnerable to malware form the network traffic received via the physical NIC 21 and P2P connection 40.
As an illustration of the problem, suppose one were to wish to protect a Windows95® guest OS from Internet viruses when it is running inside a virtual machine on a Windows XP host OS. In the FIG. 1 system, the NDIS IM drivers 24 could not be accessed; therefore, the conventional solution would be to hack together a solution using things like Network Address Translation (NAT), which greatly limits the functionality of the guest OS. A solution is desired whereby the Windows95® guest OS would be able to use some of the firewall solutions (such as the ones implemented as NDIS IM drivers like Norton firewall) available on the Windows XP host to firewall the Windows95® guest network traffic.
As a further illustration, suppose one were to wish to provide IP security support for a Windows 3.1 (or OS2 or Linux OS) guest OS running inside a virtual machine on a Windows 2003 host OS. Once again, since the IP security drivers of the host OS 20 could not be accessed, it would not be possible to provide IP security support to the guest OS unless an IP security solution exists for the guest OS (i.e., Windows 3.1 in this example) and can be managed inside the guest OS.
A solution to these problems is desired that would provide an infrastructure to support monitoring and filtering of guest network traffic by the host's NDIS IM drivers. This will give users the ability to protect legacy operating systems from Internet viruses and worms when run inside a virtual machine on a newer operating system such as Windows XP or Windows 2003 and to manage the different solutions like firewall, quality of service, IP security, and the like for different guests at one place (e.g., the host) instead of managing them inside individual guests. The present invention provides such a solution.